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Abstract 


Enabling  e-govemment  systems  to  interoperate  provides  many  benefits,  including  improved  effi¬ 
ciency,  transparency,  accountability,  and  access,  as  well  as  coordination  of  services  at  lower  costs. 
However,  repeated  failures  to  build  working  systems  show  that  the  task  is  not  only  difficult  but 
also  poorly  understood.  This  report  describes  a  proposed  model  for  understanding  interoperability 
in  the  e-govemment  context.  With  this  model,  system  developers  should  characterize  interopera¬ 
bility  in  six  dimensions:  technical,  semantic,  and  organizational,  as  well  as  legal,  political,  and 
sociocultural.  This  report  also  presents  guidance  on  how  to  address  interoperability  requirements 
and  describes  challenges  that  policy  makers  and  system  developers  face  in  achieving  interopera¬ 
bility  in  e-govemment  systems. 
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1  Introduction 


The  term  e-government  is  broadly  defined  as  the  use  of  information  and  communication  technolo¬ 
gies  to  support  the  business  of  government,  such  as  providing  or  enhancing  public  services  or 
managing  internal  government  operations.  Its  benefits  include  improved  efficiency,  transparency, 
accountability,  and  access  as  well  as  coordination  of  services  at  lower  costs.  However,  the  task  of 
delivering  these  benefits  is  not  only  difficult  but  also  poorly  understood.  Our  research  suggests 
that  interoperability  is  a  fundamental  barrier  to  achieving  the  benefits  of  e-govemment.  We  be¬ 
lieve  that  a  better  understanding  of  the  context  and  relevant  issues  will  help  resolve  the  difficulties 
many  governments  have  in  achieving  these  benefits. 

While  many  governments  have  addressed  interoperability  as  primarily  a  technical  issue,  the  full 
range  of  the  interoperability  problem  has  other  facets  and  is  influenced  by  a  variety  of  sources, 
especially  in  the  public  service  context.  To  address  the  entirety  of  the  interoperability  challenge, 
we  need  to  consider  technical  factors  such  as  data  semantics  and  process  standardization  as  well 
as  nontechnical  factors  such  as  legal,  political,  and  social  issues. 

The  purpose  of  this  report  is  to  explain  the  challenges  associated  with  achieving  interoperability 
in  e-govemment  systems  in  order  to  provide  stakeholders  of  such  systems  a  better  understanding 
of  the  context  and  thus  a  better  chance  to  succeed  in  building  them.  Section  2  discusses  the  e- 
government  context.  Section  3  explains  the  problem  of  interoperability.  Section  4  proposes  a 
model  for  understanding  interoperability  in  the  e-govemment  context.  Section  5  analyzes  how  to 
solve  the  different  facets  of  the  interoperability  problem  and  presents  an  overview  of  existing 
guidance  on  this  topic. 
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2  The  e-Government  Context 


2.1  What  Is  e-Govern merit? 

There  are  many  definitions  of  e-govemment;  the  following  are  representative: 

the  use  of  information  and  communication  technologies  (ICTs)  to  improve  the  activities  of 
public  sector  organizations  [eGovernment  for  Development  Information  Exchange  2008,  pa¬ 
ra.  1] 

the  use  of  information  technology  to  free  movement  of  information  to  overcome  the  physical 
bounds  of  traditional  paper  and  physical  based  systems  [Pascual  2003,  p.  5] 

the  use  of  technology  to  enhairce  the  access  to  and  delivery  of  government  services  to  benefit 
citizens,  business  partners  and  employees  [Deloitte  Research  2000,  p.  1] 

There  are  common  elements  to  these  and  other  definitions,  mainly  automation,  computerization, 
and  the  development  of  new  processes  to  support  government  in  the  distribution  of  public  services 
[Lungescu  2004], 

In  this  report  we  define  e-govemment  as  the  use  of  ICTs  to  support  the  business  of  government, 
such  as  providing  or  enhancing  public  services  or  managing  internal  government  operations.  This 
definition  is  general  enough  to  encompass  not  only  different  systems  and  technologies  but  also 
different  contexts.  For  example,  different  countries  have  environments  with  varying  levels  of 
available  technology,  infrastructure,  and  social  needs,  and  all  these  factors  affect  the  design  and 
implementation  of  e-govemment  services.  While  Estonia  may  have  sufficient  infrastmcture  and 
social  technological  awareness  to  have  Internet-enabled  voting  in  government  elections,  the  Phil¬ 
ippines  may  find  that  providing  simple  technologies  such  as  basic  Internet  access  and  photocopy¬ 
ing  as  public  services  has  a  significant  social  impact  [Lungescu  2004;  Broache  2005;  Alampay 
2007,  p.  4].  Our  definition  therefore  covers  technologies  ranging  from  basic  phone  support  to  ful¬ 
ly  integrated  government  portals  for  all  services  [Malotaux  2007,  p.  26]. 

2.2  What  Is  e-Government  Interoperability? 

Interoperability  in  the  e-govemment  context,  like  e-govemment  itself,  also  has  multiple  defini¬ 
tions,  such  as 

e-government  mteroperability,  in  its  broad  serzse,  is  the  ability  of  constituencies  to  work  to¬ 
gether.  At  a  technical  level,  it  is  the  ability  of  two  or  moi'e  diverse  government  information 
systems  or  components  to  meaningfully  and  seamlessly  exchange  information  and  use  the  in¬ 
formation  that  has  been  exchanged.  [UNDP  2007b,  p.  1] 

interoperability  means  the  ability  of  information  and  communication  technology  (ICT)  sys¬ 
tems  and  of  the  business  processes  they  support  to  exchange  data  and  to  enable  the  sharing 
of  information  and  knowledge.  [European  Commission  2004,  p.  5] 

Most  definitions  capture  the  general  idea  behind  interoperability  but  tend  to  focus  on  the  technical 
aspects  of  interoperability,  often  reflecting  the  belief  that  interoperability  is  primarily  a  technical 
challenge  [Pyarelal  2007,  p.  18;  Klischewski  2010,  p.  1].  As  a  result,  many  initial  efforts  at  build- 
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ing  e-govemment  systems  focus  primarily  on  these  technical  challenges  [UNDP  2007a,  p.  10;  CS 
Transform  2009,  p.  3]. 

More  recently,  system  designers  have  recognized  that  the  entire  interoperability  problem  consists 
of  more  than  technical  aspects  [UNDP  2007a,  p.  29;  European  Communities  2008,  p.  4;  Pardo 
2008,  p.  3].  Several  efforts  have  begun  to  address  the  broader  scope  [CS  Transform  2009,  p.  3]. 
One  of  the  largest  e-govemment  efforts,  the  European  Commission’s  European  Interoperability 
Framework  (EIF),  has  redefined  the  concept  of  interoperability  in  the  following  more  general 
way: 

Interoperability  is  the  ability  of  disparate  and  diverse  organizations  to  interact  towards  mu¬ 
tually  beneficial  and  agreed  common  goals,  involving  the  sharing  of  information  and 
knowledge  between  the  organizations  via  the  business  processes  they  support,  by  means  of 
the  exchange  of  data  between  their  respective  information  and  communication  technology 
(ICT)  systems.  [European  Communities  2008,  p.  5] 

This  definition  acknowledges  that  interoperability  encompasses  a  broader  range  of  issues.  Also, 
by  explicitly  citing  “common  goals,”  it  acknowledges  the  existence  of  nontechnical  influencing 
factors. 

In  this  report  we  do  not  offer  a  formal  definition  of  e-govemment  interoperability  but  simply  ar¬ 
gue  that  achieving  interoperability  requires  addressing  a  wide  range  of  technical  and  nontechnical 
issues  that  are  influenced  by  a  number  of  factors.  We  discuss  furfher  the  issues  and  factors  in¬ 
volved  in  e-govemment  interoperability  in  Section  3. 

2.3  What  Are  the  Benefits  of  Interoperability  in  an  e-Government  Context? 

The  benefits  of  achieving  e-govemment  interoperability  are  numerous  and  significant  [European 
Communities  2008,  p.  9].  From  the  standpoint  of  public  services,  we  argue  that  addressing  in¬ 
teroperability  challenges  will  improve  efficiency  of  service  delivery,  access  to  the  services,  coor¬ 
dination  among  existing  services  (resulting  in  further  efficiency  gains),  and  technology  manage¬ 
ment  and  maintenance.  In  addition,  the  administration  can  avoid  potential  future  costs  such  as 
inflexibility  due  to  vendor  lock-in  and  the  high  price  of  new  development  by  leveraging  existing 
systems  in  new  ways  [UNDP  2007a,  pp.  1-2]. 

From  the  standpoint  of  policy  makers,  e-govemment  interoperability  will  improve  data  gathering 
and  parsing  techniques,  which  will  result  in  more  efficient  decision  making  that  is  based  on  more 
accurate  information  [UNDP  2007a,  p.  1].  Improved  interoperability  will  also  enhance  transpar¬ 
ency  and  accountability,  resulting  in  better  overall  governance  [Lallana  2008,  p.  2]. 

Finally,  from  the  standpoint  of  relations  between  nations,  interoperability  can  also  promote  coop¬ 
eration  by  supporting  cross-border  efforts,  for  example,  to  interdict  dmg  trafficking  or  facilitate 
legitimate  trade  [Lallana  2008,  p.  2]. 

Despite  these  benefits,  interoperability  in  the  e-government  context  may  have  negative  effects  on 
security  and  privacy.  However,  we  decided  to  consider  security  and  privacy  issues  to  be  out  of 
scope  for  this  report.  We  chose  to  focus  primarily  on  barriers  to  interoperability  rather  than  on  the 
drawbacks  and  potential  adverse  effects  of  interoperable  e-govemment  systems. 
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2.4  Why  Is  e-Government  Interoperability  Important? 

It  is  clear  that  achieving  interoperability  in  the  e-govemment  context  will  improve  public  service 
in  a  variety  of  ways.  We  consider  improving  public  services  and  general  governance  to  be  a  key 
factor  in  meeting  the  United  Nations  Millennium  Development  goals  [UNDP  2007b,  p.  1;  Secre¬ 
tary  General,  United  Nations  2010,  p.  15].  Specifically,  improving  transparency  and  accountabil¬ 
ity  has  a  significant  impact  on  promoting  democracy  [UNDP  2007b,  p.  1]. 

From  a  different  perspective,  several  examples  of  interoperability  failures  in  public  services 
demonstrate  the  need  for  higher  levels  of  interoperability.  The  aftermath  of  the  tsunami  that  struck 
Thailand  in  2004  illustrates  the  high  cost  of  failure: 

December  26,  2004.  7:58  am.  A  thirty-foot-high  wall  of  water — a  tsunami — slams  into  the 
famed  resort  islands  off  Thailand’s  southern  coast.  In  one  tragic  moment,  thousands  of  lives 
are  lost,  and  thousands  more  are  missing. 

In  the  race  to  identify  victims  and  assist  survivors,  Thailand’s  government  hits  its  own  wall. 
Responding  agencies  and  non-governmental  groups  are  unable  to  share  information  vital  to 
the  rescue  effort.  Each  uses  different  data  and  document  formats.  Relief  is  slowed;  coordina¬ 
tion  is  complicated.  The  need  for  common,  open  standards  for  disaster  management  was 
never  more  stark  or  compelling.  [ Open  ePolicy  Group  2005,  p.  6] 

Other  more  mundane  situations  highlight  the  cost  to  both  the  service  provider  and  consumer: 

There  are  61  different  benefit  entitlement  forms — the  majority  of  which  require  the  same 
standard  information  to  be  provided  by  benefit  applicants.  In  most  cases,  links  between  the 
different  benefit  entitlements  are  not  being  made,  meaning  that  some  people  may  be  missing 
entitlements  they  are  due.  [Varney  2006,  p.  16] 

A  small  business  which  has  decided  to  recruit  a  new  staff  member  is  required  to  comply  with 
a  number  of  regulations.  Currently,  if  this  small  business  seeks  guidance  from  the  govern¬ 
ment,  it  will  be  faced  with  over  20  helplines,  links  to  more  than  25  additional  websites,  at 
least  five  codes  of practice,  and  will  need  to  be  aware  of  15  separate  regulations  on  discrim¬ 
ination,  not  all  of  which  are  covered  by  explicit  guidance.  [Varney  2006,  p.  16] 

When  we  combine  the  benefits  of  successful  interoperability  with  the  costs  of  insufficient  interop¬ 
erability,  the  case  for  pursuing  success  in  this  field  becomes  clear. 


CMU/SEI-2011-TN-014  |  4 


3  The  Interoperability  Problem 


Interoperability  is  a  complex  problem.  To  enable  interoperability  in  an  e-govemment  context,  we 
must  examine  all  its  elements. 

3.1  What  Is  Interoperability? 

Interoperability  is  another  term  that  has  many  definitions.  Ford  and  colleagues  provide  a  list  of  34 
different  definitions  [Ford  2007,  p.  2]  that  cover  a  wide  range  of  possible  meanings: 

•  from  the  very  general — “the  ability  of  systems  to  work  together”  [Morris  2004,  p.  5] 

•  to  the  very  specific — “the  ability  of  a  set  of  communicating  entities  to  (1)  exchange  specified 
state  data  and  (2)  operate  on  that  state  data  according  to  specified,  agreed-upon,  operational 
semantics”  [Morris  2004,  p.  4] 

•  to  the  very  targeted — “two-way  radio:  compatible  communications  paths  (compatible  fre¬ 
quencies,  equipment  and  signaling),  radio  system  coverage  or  adequate  signal  strength,  and 
scalable  capacity”  [Wikipedia  2011] 

Significant  research  has  provided  new  ways  to  understand  interoperability  for  many  important 
stakeholders  such  as  the  computing  community  (significantly,  the  Institute  of  Electrical  and  Elec¬ 
tronics  Engineers),  the  health  care  industry,  the  U.S.  Department  of  Defense,  and  software  re¬ 
search  institutions  [IEEE  1990,  Brownsword  2004,  Ford  2007,  Gibbons  2007,  Lewis  2008].  This 
wealth  of  research  implies  that  although  there  is  significant  interest  in  interoperability,  there  is 
little  agreement  on  what  it  is.  A  potential  reason  for  the  many  definitions  and  interpretations  is 
that  interoperability  is  situation  dependent;  its  meaning  can  vary  from  technical  to  nontechnical, 
depending  on  the  context  [Ford  2007].  We  believe  that  consensus  about  a  definition  can  be 
reached  only  at  a  high  level. 

While  researchers  cannot  agree  on  a  common  definition,  most  agree  that  we  can  break  up  the 
overall  issue  of  interoperability  into  different  types  and/or  levels  [Tolk  2003a,  2003b; 
Brownsword  2004;  Morris  2004;  Ford  2007;  Gibbons  2007;  Lewis  2008;  Wikipedia  2011].  Sys¬ 
tem  designers  typically  separate  areas  of  concern  (such  as  technical  and  nontechnical,  as  dis¬ 
cussed  in  Section  4)  by  interoperability  types  and  levels  and  organize  them  into  interoperability 
models  that  present  an  overall  perspective  of  interoperability  in  a  given  context. 

3.2  Interoperability  Models 

Just  as  there  are  many  definitions,  there  are  multiple  models  for  interoperability.  The  models 
break  down  the  interoperability  problem  into  different  types,  levels,  and/or  dimensions.  The  Lev¬ 
els  of  Information  Systems  Interoperability  (LISI)  model  breaks  down  interoperability  into  differ¬ 
ent  levels  of  connectivity  between  systems  [C4ISR  Architectures  Working  Group  1998].  The  Or¬ 
ganizational  Interoperability  Maturity  Model  (OIMM)  and  the  Levels  of  Conceptual 
Interoperability  Model  (LCIM)  build  on  the  LISI  model  in  different  ways — ^the  OIMM  model 
through  abstraction  to  command-and-control  support  and  the  LCIM  model  through  data  manage¬ 
ment — ^to  bridge  technical  design  and  conceptual  design  [Clark  1999;  Tolk  2003b;  Morris  2004, 
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pp.  6-8].  The  NATO  C3  Technical  Architecture  Reference  Model  for  Interoperability  focuses  on 
operational  effectiveness  through  data  exchange  ability  [NATO  2003].  The  Coalition  Interopera¬ 
bility  model  builds  on  a  number  of  other  models  to  construct  an  interoperability  model  that  covers 
technical  and  nontechnical  concerns  in  the  coalition  environment  [Tolk  2003a].  The  Software  En¬ 
gineering  Institute  has  proposed  both  a  system  of  systems  interoperability  model  and  an  “end-to- 
end”  interoperability  model  [Morris  2004,  pp.  9-10;  Lewis  2008].  The  European  Commission  has 
proposed  the  EIF  for  e-govemment  [UNDP  2007a,  p.  9].  Finally,  the  United  Nations  Develop¬ 
ment  Programme  (UNDP)  has  proposed  the  Government  Interoperability  Framework  (GIF)  model 
[European  Communities  2008,  p.  20]. 

In  general,  developers  define  these  models  in  terms  of  goals,  types,  and  levels  of  interoperability: 

•  An  interoperability  goal  refers  to  a  communication  capability  of  a  given  system.  For  exam¬ 
ple,  the  most  basic  goal  of  interoperability  is  the  exchange  of  information.  The  goals  in  a 
given  model  may  range  from  the  most  basic,  such  as  the  exchange  of  information,  to  very 
complex,  such  as  harmonized  strategies  in  the  LCIM  [Morris  2004].  The  goals  can  also  be¬ 
come  more  specific,  depending  on  the  granularity  of  the  goals  or  the  close  relation  to  a  par¬ 
ticular  domain  of  interest,  which  tends  to  result  in  specific  goals  related  to  that  domain. 

•  A  type  of  interoperability  usually  specifies  a  domain  of  interest  (such  as  network  interopera¬ 
bility)  or  a  goal  within  a  specific  interoperability  model.  For  example,  protocol  interoperabil¬ 
ity  is  a  specific  and  domain-dependent  type  of  interoperability  proposed  within  the  Coalition 
Interoperability  model  that  pertains  to  the  goal  that  the  communication  protocols  used  on  a 
C4ISR*  network  to  support  the  necessary  data  exchange  for  the  system  [Tolk  2003a].  In  con¬ 
trast,  the  draft  EIF  2.0  document  defines  technical  interoperability  as  the  broad  area  of  all 
“technical  aspects  of  linking  computer  systems  and  services”  [European  Communities  2008, 
p.  39]. 

•  Many  models  of  interoperability  present  levels  or  layers  of  interoperability.  As  in  any  lay¬ 
ered  model,  each  goal  or  type  of  interoperability  within  the  model  is  complementary  and 
builds  on  one  another  in  a  stack-like  form.  In  other  words,  the  model  presents  a  base  goal  or 
type  of  interoperability  and  then  places  all  of  the  other  goals  or  types  on  top  in  an  order  that 
specifies  that  each  goal  or  type  requires  all  of  the  goals  of  the  levels  below  to  be  met  to 
achieve  its  goal. 

Despite  the  similarities  in  how  they  are  defined  and  structured,  many  of  these  models  are  unsuita¬ 
ble  for  defining  a  general  interoperability  model  because  of  their  domain-specific  nature. 


C4ISR  stands  for  Command,  Control,  Communications,  Computers,  Intelligence,  Surveillance,  and  Reconnais¬ 
sance.  A  C4ISR  network  is  any  network  that  supports  these  activities. 
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4  A  Proposed  Model  for  Understanding  Interoperability  in 
the  e-Government  Context 


To  understand  interoperability  in  a  general,  domain-agnostic  way,  we  propose  a  model  that  starts 
from  the  basic  goals  of  interoperability.  We  then  map  these  goals  to  levels,  with  the  more  com¬ 
plex  goals  mapped  to  higher  levels  of  interoperability.  Finally,  we  add  the  e-govemment  context 
to  the  model  as  factors  of  influence. 

For  clarity,  we  define  a  communication  to  be  some  exchange  of  data  between  two  participants 
through  some  medium  that  may  or  may  not  have  meaning  attached.  We  define  participants  as  the 
ultimate  senders  and  receivers  of  the  data  exchanged,  that  is,  the  entities  that  use  the  data  in  a 
manner  other  than  simply  facilitating  the  exchange.  For  example,  in  a  scenario  in  which  two  hu¬ 
mans  communicate  using  cell  phones,  the  humans  are  considered  the  participants  and  all  of  the 
hardware  and  software  infrastructure  elements  facilitating  the  exchange  are  not  considered  partic¬ 
ipants  as  they  only  receive,  process,  and  send  the  data  to  move  it  from  one  participant  to  the  other. 
Flowever,  in  such  a  system  there  are  likely  computer  systems  that  monitor  the  conversation  for 
audit  logging,  and  thus  the  infrastructure  may  pass  along  direct  or  ancillary  elements  of  the  data 
exchange  to  these  systems.  Such  systems,  which  use  the  data  exchanged  for  purposes  other  than 
facilitating  the  communication,  could  also  be  considered  participants,  although  whether  or  not 
they  are  considered  active  participants  depends  on  the  given  context. 

4.1  Interoperability  Goals 

There  are  three  primary  goals  associated  with  achieving  interoperability  in  any  system  (computer 
or  otherwise):  data  exchange,  meaning  exchange,  and  process  agreement. 

4.1.1  Data  Exchange 

The  first  goal  with  respect  to  interoperability  is  basic  data^  exchange.  This  particular  goal  deals 
not  with  meaning  but  rather  with  whether  data  can  be  exchanged  at  all.  Examples  of  data  ex¬ 
change  range  from  phone  connections,  email,  and  document  exchanges  to  web  pages  and  the  au¬ 
tomated  exchange  of  data  in  computer-readable  format.  A  computer  system  example  would  be  the 
exchange  of  data  between  two  computer  systems  in  which  there  is  agreement  on  the  types  and 
size  of  the  data  exchanged,  such  as  a  number  with  two  digits  to  the  right  of  the  decimal  point.  In 
each  of  these  examples,  data  can  go  back  and  forth  without  the  participants  having  any  knowledge 
of  the  meaning  of  the  data. 

4.1.2  Meaning  Exchange 

The  second  goal  with  respect  to  interoperability  is  the  exchange  of  meaning  (i.e.,  all  participants 
in  a  given  communication  assign  the  same  meaning  to  the  information  that  is  exchanged).  To  con¬ 
tinue  the  example  in  the  previous  section,  two  computer  systems  agree  not  only  on  exchanging  a 


Even  though  the  term  information  exchange  is  most  common  in  interoperability  models,  we  use  data  exchange 
to  make  clear  that  semantics  or  meaning  is  not  exchanged  at  this  level  of  interoperability. 
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number  with  two  digits  to  the  right  of  the  decimal  point  but  also  that  the  number  corresponds  to  a 
price  in  U.S.  currency  and  does  not  include  tax. 

Meaning  exchange  is  fundamentally  different  from  data  exchange  because  of  the  aspect  of  misin¬ 
terpretation.  Data  exchange  either  occurs  or  does  not  occur.  Meaning  exchange,  however,  is  much 
more  difficult  because  there  is  no  implicit  guarantee  that  all  participants  will  interpret  the  meaning 
of  the  data  in  the  same  way.  A  well-publicized  example  illustrating  this  difficulty  is  the  met¬ 
ric/imperial  unit  issue  that  caused  the  loss  of  the  Mars  Climate  Orbiter  spacecraft  in  1999  [Lloyd 
1999].  Even  when  two  participants  agree  on  a  particular  piece  of  data  as  a  unit  of  distance,  if  both 
sides  do  not  understand  the  specific  type  of  unit  in  exactly  the  same  way,  there  is  potential  for 
failure  or  even  disaster. 

4.1.3  Process  Agreement 

The  third  goal  with  respect  to  interoperability  is  agreement  on  how  to  act  on  information  that  has 
been  exchanged  (i.e.,  whether  all  participants  in  a  given  communication  have  the  same  under¬ 
standing  of  how  to  act  once  they  have  exchanged  information).  Process  agreement  is  a  fundamen¬ 
tally  different  type  of  interoperability  goal  from  the  previous  two  types,  data  exchange  and  mean¬ 
ing  exchange,  because  its  focus  shifts  from  the  information  exchanged  to  the  actions  taken  by  the 
participants  once  the  information  exchange  has  occurred. 

To  achieve  process  agreement,  all  participants  must  agree  in  advance  about  what  to  do  with  the 
data  they  receive  in  the  exchange.  To  further  extend  the  computer  system  example,  assume  that 
the  exchanged  price  corresponds  to  the  quoted  price  for  a  certain  article  and  that  the  receiving 
party  must  acknowledge  this  price  via  a  predefined  acknowledgment  message  within  24  hours  for 
the  price  to  remain  valid. 

Process  agreements  are  often  complex  and  represent  many  of  the  problems  that  e-govemment 
efforts  attempt  to  address.  Lack  of  process  agreement  often  manifests  as  a  need  for  the  consumer 
to  provide  the  same  information  to  multiple  government  services  in  response  to  a  single  event.  For 
example,  one  documented  case  in  the  United  Kingdom  from  2004  showed  that  the  process  of  a 
typical  family  making  the  necessary  arrangements  with  the  government  to  handle  the  death  of  a 
family  member  required  44  different  interactions  with  government  offices  and  was  still  unre¬ 
solved  after  180  days  [Varney  2006,  p.  16].  This  example  might  be  an  extreme  case,  but  improv¬ 
ing  the  efficiency  of  and  coordination  between  government  agencies  to  minimize  unreasonable 
overhead  for  citizens’  use  of  public  services  is  a  primary  benefit  of  e-govemment  interoperability 
[UNDP  2007a,  pp.  1-2;  European  Communities  2008,  p.  1 1]. 

4.2  Interoperability  Levels 

The  rationale  for  interoperability  levels  is  to  indicate  how  interoperability  goals  can  build  on  each 
other  to  achieve  more  complex  goals.  On  the  basis  of  the  interoperability  goals  presented  in  the 
previous  section,  we  have  established  the  following  levels,  as  shown  in  Figure  1 . 
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Systems  can  participate  in  multi¬ 
organization  business  processes 


Organizational 


Process  Agreement 


Semantic 

Meaning  Exchange 


Systems  can  exchange  meaningful  data 


Technical 

Data  Exchange 


Systems  can  exchange  data 


Figure  1:  Interoperability  Levels 

4.2.1  Technical  Interoperability 

Technical  interoperability  maps  to  the  goal  of  data  exchange.  We  place  technical  interoperability 
at  the  base  level  because  the  exchange  of  data  is  at  the  root  of  all  communication.  In  some  of  the 
more  technically  based  interoperability  models,  this  level  is  divided  into  sublevels  that  map  to 
specific  modes  of  communication  and  separate  the  data  from  the  communication  channel  [Tolk 
2003b,  Lewis  2008].  The  approach  taken  in  existing  e-govemment  interoperability  models  is  to 
abstract  the  details  of  the  communication  and  have  a  single  level,  which  is  the  approach  that  we 
have  selected  [UNDP  2007a,  p.  9;  European  Communities  2008,  p.  39]. 

4.2.2  Semantic  Interoperability 

Semantic  interoperability  maps  to  the  goal  of  meaning  exchange.  We  placed  it  above  the  technical 
interoperability  level  because  in  order  to  exchange  meaning  it  is  necessary  to  have  already  been 
successful  at  information  exchange.  This  is  consistent  with  many  of  the  existing  interoperability 
models  [Gibbons  2007,  pp.  14-15;  UNDP  2007a,  p.  9;  European  Communities  2008,  p.  38;  Lewis 
2008;  Stroetmann  2009;  Wikipedia  2010b]. 

4.2.3  Organizational  Interoperability 

Organizational  interoperability  maps  to  the  goal  of  process  agreement.  We  placed  it  at  the  top  lev¬ 
el  because  process  agreement  cannot  occur  without  both  information  exchange  and  meaning  ex¬ 
change  supporting  the  communication  to  establish  the  process  and  the  communication  that  con¬ 
tains  the  information  for  the  recipient  to  act  on. 

The  organizational  interoperability  level  is  consistent  with  some  of  the  interoperability  models, 
especially  in  the  e-govemment  context  [UNDP  2007a,  p.  9;  European  Communities  2008;  Lewis 
2008].  Some  models  describe  this  level  in  a  more  technical  way  as  process  interoperability  [Gib¬ 
bons  2007,  p.  15].  Other  models  include  process  as  an  important  concept  with  respect  to  interop¬ 
erability  but  do  not  include  a  specific  goal  or  level  [Tolk  2003a,  2003b].  Although  the  term  pro¬ 
cess  interoperability  describes  the  interoperability  goal  of  process  agreement  more  directly, 
organizational  interoperability  is  a  better  term  for  the  e-govemment  context  because  it  captures 
the  scope  of  inter-  and  intra-organizational  process  alignment  that  is  necessary  to  meet  this  in¬ 
teroperability  goal. 
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4.3  Influencing  Factors 

The  e-govemment  context  is  complex  because  it  has  to  deal  with  legal,  politics  and  policy,  and 
sociocultural  issues.  For  example,  the  independent  nature  of  government  agencies  and  conflicting 
leadership,  policy,  and  financial  priorities  make  it  difficult  to  enable  consolidation  and  coopera¬ 
tion  in  the  pursuit  of  better  citizen  services  [Biddick  2009]. 

In  our  proposed  interoperability  model,  we  represent  this  additional  impact  of  legal,  political  (pol¬ 
icy),  and  sociocultural  issues  as  influencing  factors.  These  factors  are  captured  in  this  way  and  not 
as  an  additional  level  for  these  reasons: 

•  The  impact  of  each  is  different,  depending  on  the  situation. 

•  They  apply  to  almost  any  e-govemment  system,  regardless  of  the  intended  interoperability 
level. 

For  example,  even  a  simple  website  that  shares  information  with  the  public  has  to  consider  legal 
issues  such  as  what  information  is  considered  public,  political  issues  such  as  consistency  with 
current  policies  and  objectives,  and  sociocultural  issues  such  as  accessibility  for  non-English 
speakers. 

From  a  system-developer  perspective,  these  factors  become  an  additional,  critical  dimension  of 
the  interoperability  problem,  and  any  e-govemment  effort  must  address  them.  Reaching  any  in¬ 
teroperability  level  requires  solutions  to  be  compliant  with  legal,  political,  and  sociocultural  fac¬ 
tors,  as  shown  in  the  proposed  interoperability  model  in  Figure  2. 


Interoperability 

Levels 
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processes 


Systems  can  exchange 
meaningfui  data 


Systems  can  exchange  data 


Legal 
power 
assigned 
to  system 
capabiiities 


Poiiticai 

context 

and 

support  for 
system 
capabilities 


Social  and 
cultural 
characteristics 
of  system 
stakeholders 


Influencing  Factors 


Figure  2:  e-Government  Interoperability  Model 
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4.3.1  Legal  Factors 


One  of  the  primary  concerns  from  a  legal  standpoint  is  the  assignment  of  legal  weight  to  the  out¬ 
puts  of  a  given  e-govemment  system  so  that  the  system  can  support  or  replace  existing  manual 
public  services  [European  Communities  2008,  p.  33].  Identifying  legal  issues  inherent  to  public 
services  is  critical  not  only  to  enable  appropriate  e-govemment  services  but  also  to  identify  ser¬ 
vices  that  are  not  appropriate  for  the  e-govemment  context.  For  example,  the  Department  of 
Transportation  for  the  U.S.  state  of  Pennsylvania  (PennDOT)  does  not  offer  online  access  to  mo¬ 
tor  vehicle  title-application  forms,  requiring  registrants  physically  to  appear  at  an  Information 
Center  with  the  necessary  information,  presumably  for  security  reasons  [PennDOT  2011a].  How¬ 
ever,  other  services  that  potentially  have  less  impact  if  they  are  compromised,  such  as  license  re¬ 
newal  or  change  of  address,  are  offered  directly  through  the  department  website  [PennDOT 
2011a]. 

Another  area  where  legal  concerns  are  important  is  the  assignment  of  responsibility.  All  e- 
govemment  systems  must  fully  comply  with  relevant  laws,  mles,  and  regulations,  which  can  im¬ 
pose  a  high  cost  of  failure.  This  can  include  regulations  with  respect  to  administrative  law,  intel¬ 
lectual  property  rights,  and  privacy  and  data-protection  issues  [European  Communities  2008,  p. 
34].  The  e-govemment  systems  must  be  legally  responsible  for  these  concerns,  and  this  places  a 
significant  burden  on  the  design,  development,  and  maintenance  of  these  systems.  System  design¬ 
ers  must  arrange  for  legal  review  of  any  potential  failure  of  an  e-govemment  system  to  comply 
with  laws  and  policies;  determine  the  appropriate  response  to  the  failure;  and,  if  necessary,  carry 
out  that  response. 

The  draft  2.0  version  of  the  EIF  proposes  an  additional  layer  of  interoperability  called  “legal  in¬ 
teroperability”  that  addresses  these  concerns  [European  Communities  2008,  p.  34].  This  is  a  posi¬ 
tive  step  toward  recognizing  the  impact  of  legal  concerns  in  the  e-govemment  context.  However, 
creating  a  new  level  of  interoperability  for  this  layer  is  misleading  because  dealing  with  legal  con¬ 
cerns  does  not  result  in  addressing  a  new  interoperability  goal;  rather,  it  influences  the  three  in¬ 
teroperability  goals  already  identified.  As  an  example,  legal  concerns  can  affect  the  exchange  of 
data  by  mandating  that  it  is  exchanged  in  a  way  that  is  secure  and  preserves  privacy.  In  addition, 
legal  concerns  may  affect  the  meaning  of  the  information  that  is  exchanged  by  mandating  all  in¬ 
formation  to  be  collected  in  a  race-neutral  way  in  order  to  prevent  discrimination.  Finally,  legal 
concerns  may  affect  process  agreement  by  mandating  hospital  emergency  rooms  to  provide  stabi¬ 
lizing  care  to  all  who  request  it,  resulting  in  processes  that  support  this  requirement. 

4.3.2  Political  Factors 

The  political  context  in  which  we  introduce  e-govemment  systems  is  critically  important  to  the 
success  of  any  e-govemment  interoperability  effort.  For  example,  the  Gartner  report  on  the  EIF 
2.0  update  lists  four  general  areas  of  concern  that  contain  barriers  to  e-govemment  interoperabil¬ 
ity:  policy  makers,  administrations,  IT  departments,  and  accessibility  [Malotaux  2007,  pp.  20—21]. 
Within  those  four  areas,  only  two  note  any  technical  issues,  while  coordination  among  different 
agencies  and  departments  is  a  common  theme  across  all  areas.  The  Varney  report  lists  six  primary 
barriers  to  interoperability,  five  of  which  deal  with  agency  coordination  and  budgetary  issues 
[Varney  2006,  pp.  17—18].  The  draft  EIF  2.0  document  lists  political  context  as  its  highest  level  of 
interoperability  [European  Communities  2008,  p.  32].  This  report  acknowledges  that  guidance  is 
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difficult  to  define  for  this  area  of  interest  but  that  political  support  is  critical  for  e-govemment 
interoperability  success  [European  Communities  2008,  p.  32]. 

The  common  theme  in  issues  mentioned  in  these  reports  is  political  will.  A  government  admin¬ 
istration  that  has  the  political  will  and  power  to  organize,  manage,  and  fund  an  e-govemment  in¬ 
teroperability  project  in  a  way  that  addresses  all  of  the  interrelated  issues  will  have  a  much  better 
chance  for  success.  Without  this  critical  element,  it  can  be  difficult  to  realize  the  level  of  coopera¬ 
tion  and  coordination  among  the  participating  government  departments  necessary  to  address  the 
technical,  semantic,  and  organizational  interoperability  challenges  that  an  e-government  project 
may  have. 

4.3.3  Sociocultural  Factors 

The  final  influencing  factors  that  designers  must  consider  when  engaging  in  an  e-govemment  in¬ 
teroperability  project  are  social  and  cultural  concerns.  The  potential  sources  of  impact  in  this  area 
vary  widely,  depending  on  the  context  of  the  effort.  For  example,  in  ethnically  diverse  regions  it 
may  be  necessary  to  deliver  public  services  through  different  channels  or  customizable  channels. 
An  example  of  systems  influenced  by  social  and  cultural  concerns  is  the  Spanish-language  option 
that  is  available  in  the  United  States  when  calling  most  public  service  department  phone  numbers. 
The  EIF  mandates  a  “multi-channel  approach”  to  compensate  for  socioeconomic  disparities  and 
multilingualism  as  a  key  factor  for  building  interfaces  to  public  services  [European  Commission 
2004,  p.  8].  Additionally,  other  sociocultural  factors  such  as  religion  and  language  may  also  affect 
e-govemment  interoperability  efforts. 

While  social  and  cultural  factors  can  affect  all  three  levels  of  interoperability,  we  also  stress  that 
they  are  critical  to  another  aspect — ^user  adoption.  Designers  can  develop  services  that  meet  the 
goals  of  the  government  and  the  needs  of  the  citizens,  but  if  the  target  users  do  not  consider  them 
accessible  and  usable,  they  may  not  adopt  those  services.  In  turn,  the  services  will  not  realize  their 
full  potential. 
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5  Addressing  the  e-Government  Interoperability  Problem 


The  context  for  every  e-govemment  project  is  different:  different  services  require  different  tech¬ 
nologies,  different  semantics,  and  different  processes,  and  they  are  influenced  by  different  factors. 
The  combination  of  desired  services  and  the  context  in  which  the  provider  will  deliver  them 
drives  interoperability  requirements.  Although  we  can  apply  concepts  such  as  maturity  levels  or 
frameworks  to  the  e-govemment  context,  this  can  be  misleading  [Pardo  2008,  p.  9].  While 
frameworks  and  models  can  certainly  help  us  set  expectations  and  focus  on  problems,  assigning 
maturity  levels  often  results  in  an  implication  that  “higher  is  better”  [Phillips  2009].  Instead,  we 
argue  that  the  correct  approach  is  to  find  the  level  of  interoperability  that  best  delivers  the  specific 
public  service  or  services  being  developed.  Especially  in  e-govemment,  interoperability  is  not 
necessarily  machine  to  machine.  There  are  many  cases  for  which  the  solution  is  human  to  ma¬ 
chine  or  even  human  to  human.  The  following  sections  provide  examples  and  guidance  for  ad¬ 
dressing  some  of  the  challenges  for  systems  interoperability  in  the  e-govemment  context. 

5.1  Interoperability  Is  Contextual 

To  illustrate  how  different  systems  have  different  interoperability  requirements,  it  is  useful  to  ex¬ 
amine  a  number  of  example  systems  that  meet  the  needs  of  the  communities  they  serve. 

5.1.1  Public  Services  in  Countries  with  Poor  Infrastructures 

One  example  of  technologically  basic  yet  effective  public  services  is  the  Community  e-Centers 
(CeC)  in  the  Philippines  [Alampay  2007,  pp.  4-12].  CeCs  are  shared-access  facilities  that  allow 
local  residents  to  access  basic  services  such  as  the  Internet,  photocopying,  and  distance-learning 
tools  as  well  as  support  other  government  services  in  the  education,  business,  and  health  areas. 
Because  rural  areas  in  the  Philippines  typically  have  limited  computer  and  Internet  access,  the 
basic  technological  services  that  more  connected  countries  take  for  granted  are  extremely  useful 
in  this  context  and  represent  a  perfect  fit. 

A  notable  characteristic  of  the  Philippines  CeC  effort  is  that  the  system  does  not  really  have  to 
address  the  organizational  and  semantic  interoperability  levels.  Technical  interoperability,  imple¬ 
mented  by  setting  up  the  Internet  connection  and  access  machines,  is  sufficient  for  this  effort. 
However,  social  and  cultural  factors  certainly  came  into  play  in  deciding  on  this  solution  (e.g., 
developing  tutors  and  training  programs  because  most  CeC  users  do  not  know  how  to  use  com¬ 
puters).  Political  factors  come  into  play  with  the  budgeting  and  management  of  the  distribution 
effort.  The  CeC  system  provides  an  example  of  the  interplay  of  interoperability  requirements  and 
influencing  factors  that  designers  should  consider  to  implement  a  successful  public  service. 

5.1.2  Public  Services  in  Developed  Countries 

In  more  developed  countries,  some  government  services  are  offered  via  web  portals  [Malotaux 
2007,  pp.  23-28].  An  example  of  this  type  of  service  is  the  PennDOT  website  from  Pennsylvania, 
which  offers  simple  services  such  as  change  of  address  and  scheduling  of  driver’s  license  exams 
directly  through  the  site  [PennDOT  2011b].  To  access  any  of  the  services,  a  user  has  to  submit 
information  to  verify  identity  as  well  as  any  information  required  by  the  specific  service  (e.g.. 
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driver’s  license  number,  new  and  old  address,  test  location,  and  test  date).  To  facilitate  this,  the 
website  has  to  be  implemented  to  capture  information  from  the  user,  validate  the  information,  per¬ 
form  the  necessary  actions,  and  inform  the  user  of  the  results.  This  represents  the  technical  in¬ 
teroperability  requirements  of  the  system.  The  website  specifies  how  to  enter  certain  information 
(e.g.,  the  format  of  the  vehicle  license  plate  number)  and  provides  additional  help  to  fill  out  the 
fields  on  the  form.  This  is  an  example  of  semantic  interoperability  requirements  to  make  sure  that 
the  user  understands  the  meaning  of  the  entered  information.  On  the  change  of  address  form,  there 
is  an  option  to  notify  the  county  voter  registration  office  of  the  change  of  address.  This  means 
there  should  be  a  semantic  interoperability  requirement  between  the  two  organizations  such  that 
they  agree  on  the  meaning  of  the  information  exchanged  so  that  the  service  assigns  the  user  to  the 
proper  voting  site. 

Although  in  some  cases  the  underlying  processes  surrounding  the  transaction  appear  to  be  rela¬ 
tively  simple — for  example,  a  user  submits  identifying  information  and  requested  changes  and 
PennDOT  processes  information  and  provides  confirmation — both  sides  have  process  expecta¬ 
tions  that  illustrate  the  organizational  interoperability  requirements  of  the  system.  In  the  case  of  a 
change  of  address,  the  user  expects  to  receive  a  change  of  address  stub  in  the  mail  within  a  num¬ 
ber  of  days  to  use  as  a  proof  of  address.  In  a  more  complex  service  that  requires  payment,  such  as 
renewing  a  driver’s  license,  organizational  interoperability  requirements  must  exist  between 
PennDOT  and  the  online  credit  card  processing  companies.  Finally,  the  system  takes  into  account 
legal  factors  such  as  privacy  requirements  (a  privacy  statement  is  accessible  from  every  page), 
social  factors  such  as  a  common  aversion  to  physically  traveling  to  a  DoT  facility,  and  political 
factors  such  as  funding  and  management  of  the  department  [fntelligenius  Dot  Net  2010]. 

5.1.3  Public  Services  in  Highly  Connected  Countries 

Flighly  connected  countries,  especially,  provide  examples  of  public  services  with  high  levels  of 
interoperability.  One  of  the  most  notable  is  the  X-Road  project  run  by  the  government  of  Estonia 
[Malotaux  2007,  p.  26].  As  one  of  the  most  technologically  advanced  countries  in  the  European 
Union,  Estonia  has  established  the  X-Road  system  as  a  primary  gateway  to  services  offered  by  all 
government  agencies  in  the  country  [Lungescu  2004].  This  has  even  enabled  the  institution  of  one 
of  the  first  examples  of  online  voting,  a  public  service  that  has  significant  privacy  and  security 
implications  [Broache  2005]. 

Although  we  do  not  have  access  to  the  actual  interoperability  requirements  of  the  Estonian  X- 
Road  system,  if  we  use  the  case  of  electronic  voting,  we  can  assume  there  are  technical  interoper¬ 
ability  requirements  to  confirm  that  a  voter’s  vote  is  registered,  semantic  interoperability  require¬ 
ments  to  make  sure  that  the  voter  voted  for  the  desired  candidate,  and  organizational  interopera¬ 
bility  requirements  to  carry  out  the  collection,  protection,  counting,  and  certification  of  the  votes. 
The  legal,  political,  and  social  influencing  factors  for  such  a  service  should  be  clear  and  would 
cause  the  service  to  fail  if  designers  did  not  address  them  (e.g.,  accessibility  to  ensure  that  legal 
citizens  can  vote,  party-neutral  user  interface  that  does  not  show  any  preference  or  privileged  po¬ 
sition  for  any  party,  and  audit  mechanisms  to  support  recounts  or  challenges  to  election  results). 

5.2  Addressing  Interoperability  Requirements 

Because  every  e-govemment  system  is  context  dependent,  every  project  must  identify  and  analyze 
its  interoperability  requirements  and  the  influencing  factors  relevant  to  its  own  context.  The  fol- 
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lowing  sections  present  some  guidance  on  how  to  address  interoperability  requirements  and  influ¬ 
encing  factors. 

5.2.1  Addressing  Technical  Interoperability 

To  enable  information  exchange  at  any  level,  governments  must  select  compatible  technology 
solutions.  This  can  be  as  simple  as  standardizing  a  form  or  restricting  communication  to  phone 
calls  or  as  complex  as  selecting  web  service  security  standards.  Regardless  of  the  selected  tech¬ 
nology  solution,  service  designers  must  consider  a  number  of  issues  to  ensure  that  the  technology 
solution  is  appropriate.  This  effort  should  begin  by  examining  how  e-govemment  stakeholders 
have  historically  attempted  to  solve  the  problem  and  identifying  the  issues  relevant  to  their  con¬ 
text. 

5. 2. 1.1  Technology  Catalogs 

When  governments  first  started  thinking  in  earnest  about  e-government  interoperability  in  the 
1 990s,  the  technology  landscape  presented  some  real  challenges  in  the  technical  interoperability 
layer  [CS  Transform  2009].  In  the  United  Kingdom,  the  government  recognized  that  one  of  the 
key  challenges  was  to  restrain  various  ministries  from  creating  custom  and  noninteroperable  solu¬ 
tions,  so  the  first  U.K.  eGovemment  Interoperability  Framework  (eGIF)  published  in  2000  ad¬ 
dressed  that  issue  by  stating  that  “by  adopting  Internet  and  World  Wide  Web  standards,  the 
Framework  aligns  government  with  the  rest  of  industry”  [Minister  for  the  Cabinet  Office  2001]. 

Numerous  countries  have  followed  the  United  Kingdom’s  lead  over  the  past  decade,  establishing 
“standards  catalogues”  that  contain  approved  technologies  for  use  in  a  country’s  e-government 
systems  [Floel  2009].  These  catalogs  enable  a  country  to  establish  some  commonality  in  the  tech¬ 
nologies  used  by  different  services  across  different  agencies  or  ministries.  Using  technical  stand¬ 
ards  to  constrain  technology  procurement  across  departments  and  agencies  is  a  proven  method  for 
promoting  technical  interoperability  among  large  numbers  of  interacting  entities  [Lewis  2008]. 

5. 2. 1.2  Use  of  Open  Standards 

A  common  theme  in  the  e-govemment  context  is  the  use  of  open  standards  to  promote  interopera¬ 
bility  [Pyarelal  2007,  p.  18;  UNDP  2007b,  p.  3;  Watlegama  2007;  European  Communities  2008, 
p.  53;  Government  of  India  2008].  Although  it  is  difficult  to  define  open  standard,  many  stand¬ 
ards  stakeholders  do  agree  on  several  key  attributes.  For  example,  a  group  of  the  world’s  leading 
telecommunications  and  radio  standards-setting  organizations  known  as  the  Global  Standards 
Collaboration  has  suggested  the  following  attributes  [Global  Standards  Collaboration  2009,  Inter¬ 
national  Telecommunication  Union  2011]: 

•  The  standard  is  developed,  approved,  and  maintained  by  a  collaboralive  consensus-based 
process. 

•  Such  process  is  transparent. 

•  The  process  includes  materially  affected  and  interested  parties. 
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•  The  standard  is  subject  to  RAND/FRAND^  Intellectual  Property  Right  (IPR)  policies,  which 
do  not  mandate,  but  may  permit  at  the  option  of  the  IPR  holder,  licensing  essential  intellec¬ 
tual  property  without  compensation. 

•  The  standard  is  published  and  made  available  to  the  general  public  under  reasonable  terms 
(including  for  a  reasonable  fee  or  for  free). 

Open  standards  are  important  to  governments  because  they  can  increase  the  number  of  compatible 
offerings  (which  leads  to  lower  switching  costs)  and  because  wide  stakeholder  participation  may 
increase  the  quality  and  suitability  of  the  standard  [European  Communities  2008].  However,  open 
standards  are  not  always  the  solution  because  there  will  always  be  domains  where  open  standards 
do  not  yet  exist.  So  in  some  areas,  at  least  for  an  interim  period,  governments  may  find  them¬ 
selves  using  so-called  de  facto  standards  that  are  controlled  by  a  single  company  or  small  group  of 
companies  [European  Communities  2008,  Lewis  2008].  In  addition,  the  open  and  consensus- 
based  process  that  is  typical  of  an  open  standard  may  not  keep  up  with  the  rapid  speed  of  innova¬ 
tion  in  the  technology  world.  In  the  end,  standards  are  successful  if  widely  implemented,  and  wide 
implementation  in  turn  depends  on  a  number  of  factors  that  include  the  relevance  of  the  standard, 
the  process  of  adoption  (open,  transparent),  and  the  quality  of  the  documentation  [European 
Communities  2008]. 

5. 2. 1.3  Understanding  Limitations  of  Standards 

Standards  are  clearly  an  important  component  of  technical  interoperability.  However,  we  must 
stress  the  risks  of  placing  too  much  emphasis  on  technical  standards  and  the  limitations  of  what  a 
standards  catalog  will  provide  in  the  context  of  eGIFs. 

First,  the  selection  of  technology  standards  will  not  guarantee  semantic  or  organizational  interop¬ 
erability  [Lewis  2008].  Even  though  there  are  languages  for  modeling  information  meaning  and 
processes  to  support  interoperation  in  these  areas,  the  fundamental  limitation  is  human  agreement: 
All  parties  must  agree  on  what  a  data  point  means  and  what  to  do  with  it.  No  current  technology 
can  make  those  decisions  automatically,  and  it  is  unlikely  that  any  technology  ever  will.  We  dis¬ 
cuss  this  topic  further  in  Section  5.2.2. 

Second,  there  are  risks  in  relying  on  standards  to  achieve  technical  interoperability.  According  to 
Lewis  and  colleagues,  standards  evolve,  often  break  backward  compatibility,  are  inconsistently 
specified,  can  become  unstable  or  irrelevant,  and  can  conflict  or  compete  with  other  standards 
[Lewis  2008].  Also,  mandating  standards  that  are  not  yet  mature  enough  for  wide  adoption  can 
affect  their  evolution  [CS  Transform  2009,  p.  3].  Finally,  placing  too  much  focus  on  standard  se¬ 
lection  can  distract  attention  from  the  equally  important  effort  of  addressing  semantic  and  organi¬ 
zational  interoperability  [CS  Transform  2009,  p.  3].  For  example,  a  recent  e-govemment  effort  in 
Egypt  that  utilized  a  technology-first  approach  resulted  in  significant  infrastructure  improvements 
but  no  actual  public  service  improvements,  primarily  because  of  lack  of  “organizational  readi¬ 
ness”  to  leverage  the  delivered  technology  [Klischewski  2010,  p.  8]. 

Third,  selecting  a  standard  to  solve  a  technical  interoperability  problem  requires  agreement,  or  at 
least  rough  consensus,  and  as  a  result  it  may  not  be  possible  for  governments  prospectively  to  list 


RAND/FRAND  stands  for  reasonable  and  nondiscriminatory/fair,  reasonable,  and  nondiscrimlnatory  [Phipps 
2010]. 
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standards  for  all  domains  of  interaction  among  the  government,  citizens,  and  businesses.  This  is 
especially  true  in  nascent  areas  of  technology,  such  as  education: 

Standards  catalogues  are  a  means  by  which  governments  may  lead  and  coordinate  develop¬ 
ment  in  certain  domains.  We  have  highlighted  that  in  the  [learning  education  technology] 
domain  this  might  not  be  effective,  and  alternative  approaches  should  be  found.  [Hoel  2009, 
p.  241] 

Finally,  researchers  and  marketers  are  increasingly  discussing  the  role  that  these  standards  lists 
play  in  today’s  world. 

Much  of  the  technical  content  in  many  IFs  [interoperability  frameworks]  is  at  a  level  of  de¬ 
tail  which,  nowadays,  is  unnecessary.  The  market  has  matured  significantly  in  recent  years, 
so  the  solutions  to  many  of  what  were  previously  seen  as  technical  barriers  to  interoperabil¬ 
ity  are  now  “designed  in  ”  to  a  wide  choice  of  competitive,  commercial  products.  [CS  Trans¬ 
form  2009,  p.  3] 

5. 2. 1.4  Understanding  and  Preparing  for  Evoiution  of  Standards 

Technology  changes  over  time  and  precipitates  corresponding  changes  in  any  standards  selected 
for  an  e-govemment  effort.  Thus,  standards  will  need  to  be  updated  even  if  they  are  appropriate 
for  the  context  at  the  time  they  are  implemented.  To  fully  leverage  a  technology  standard,  adopt¬ 
ing  organizations  must  actively  manage  the  impact  of  changes  to  the  standard  on  the  systems  in 
which  it  is  used,  which  involves  deciding  when  to  adopt,  upgrade,  switch,  and/or  discontinue  use. 
Failing  to  compensate  for  changes  in  the  standard  can  result  in  a  number  of  potential  issues,  such 
as  incompatibilities  with  newer  products  and  the  need  for  workarounds  so  that  existing  products 
retain  their  value  [Lewis  2008]. 

5.2.2  Addressing  Semantic  interoperabiiity 

To  support  semantic  interoperability  in  a  technological  context,  public  service  providers  have  to 
agree  on  several  characteristics  of  the  data  to  be  exchanged,  including  data  attributes  such  as 

•  units  (e.g.,  metric  versus  imperial  units) 

•  validity  (e.g.,  retirement-related  information  is  valid  only  if  the  age  of  the  person  is  greater 
than  65) 

•  time  period  (e.g.,  a  policy  may  not  apply  if  an  event  occurred  during  a  certain  period  of  time) 

Achieving  semantic  interoperability  is  a  difficult  problem  that  is  largely  unsolved  within  the  e- 
government  context  [European  Communities  2008,  p.  38].  Stakeholders  typically  achieve  seman¬ 
tic  interoperability  through  direct  negotiation  until  they  reach  a  consensus.  One  common  approach 
to  building  this  consensus  is  to  construct  an  ontology  or  set  of  ontologies,  which  are  basically  data 
models  that  define  the  data  items  that  are  exchanged — including  the  exact  meaning  and  structure 
assigned  to  them — and  the  relationships  between  data  items.  Technologies  that  support  ontology 
generation  include  OWL  and  XBRL  [Wikipedia  2010a]. 

There  are  limitations  in  the  use  of  ontologies  and  other  semantic  interoperability  solutions.  First, 
while  data  models  generally  cover  only  a  single  domain  or  area  of  concern,  the  typical  e- 
govemment  system  will  probably  need  to  understand  multiple  areas  of  concern  to  operate  correct¬ 
ly.  For  example,  an  emergency  response  system  must  be  concerned  about  map  data,  weather  data. 
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logistics  data,  health  data,  and  citizen  data.  Each  of  these  areas  of  concern  may  represent  the  same 
data  in  a  different  way.  Second,  consumers  of  data  models  require  different  levels  of  detail,  ag¬ 
gregation,  and/or  summarization.  For  example,  a  data  model  for  meteorological  data  can  be  ex¬ 
tremely  detailed  to  support  a  scientist  conducting  studies  on  weather  patterns  and  effects,  whereas 
the  typical  consumer  may  be  interested  only  in  today’s  weather  forecast.  Third,  areas  of  concern 
tend  to  evolve,  requiring  maintenance  of  existing  data  models  and  in  some  cases  generation  of 
new  ones.  Finally,  it  can  be  difficult  for  any  community  of  interest  to  reach  consensus  on  any  area 
because  people  tend  to  interpret  information  in  slightly  different  ways. 

5.2.3  Addressing  Organizational  Interoperability 

To  enable  organizational  interoperability  in  the  e-govemment  context,  public  service  providers 
have  to  agree  on  not  only  what  information  is  exchanged,  when  it  is  exchanged,  and  how  it  is  ex¬ 
changed  but  also  what  to  do  with  it  when  it  is  exchanged.  Stakeholders  typically  achieve  organi¬ 
zational  interoperability  in  a  manner  similar  to  semantic  interoperability,  by  negotiating  directly  to 
come  to  a  consensus  on  the  processes  they  will  use. 

Addressing  organizational  interoperability  is  also  similar  to  addressing  semantic  interoperability: 
The  process  is  primarily  manual,  and  a  few  tools  are  available  to  automate  the  process.  For  exam¬ 
ple,  BPEL  and  YAWL  are  languages  that  can  be  used  to  model  processes  for  web  services 
[OASIS  2007,  YAWL  Foundation  2009].  For  a  more  general  approach,  BPMN  can  be  used  to 
graphically  model  business  processes  [OMG  2011]. 

Processes  evolve  in  ways  similar  to  data  models  and  technological  standards  and  thus  incur  the 
same  maintenance  costs.  Agreement  by  communities  of  interest  on  processes  can  also  be  hard  to 
reach  for  the  same  reasons  and  also  because  different  organizations  tend  to  use  different  business 
processes  to  create  competitive  advantages."^  Different  organizations  also  have  different  (and 
sometimes  directly  conflicting)  goals,  so  there  may  be  scenarios  in  which  technical  and  semantic 
interoperability  exists  between  two  government  entities,  but  because  of  their  competing  goals  the 
organizations  will  not  agree  to  work  together. 

5.2.4  Addressing  Influencing  Factors 

Even  though  necessary  for  successful  implementation  of  e-government  systems,  guidance  for 
dealing  with  legal,  political,  and  sociocultural  influencing  factors  is  beyond  the  scope  of  this  re¬ 
port.  Some  newer  guidance  on  e-govemment  interoperability  discusses  these  factors,  such  as  the 
draft  EIF  2.0  document  [European  Communities  2008,  p.  38]. 

5.3  Existing  Guidance 

Interoperability  in  the  e-govemment  domain  is  becoming  a  more  popular  research  topic  as  more 
governments  attempt  to  stand  up  their  own  systems  and  stakeholders  better  understand  the  scope 
of  the  challenge.  The  UNDP  has  published  several  documents  outlining  GIFs  [Varney  2006,  p.  2; 
Lallana  2007;  UNDP  2007a,  2007b].  These  guides  are  a  good  place  to  start  framing  the  problem 
and  provide  a  good  overview  of  e-govemment  interoperability  efforts  across  the  globe.  However, 


While  competitive  advantage  is  certainly  a  driver  for  developing  different  processes  in  the  private  sector,  this  is 
less  of  a  concern  in  the  e-government  domain.  However,  it  may  still  become  a  factor  in  business-government  in¬ 
teractions. 
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readers  should  be  cautioned  that  these  documents  tend  to  focus  on,  and  result  in,  interoperability 
efforts  mainly  at  the  technical  level  [UNDP  2007a,  CS  Transform  2009]. 

Another  significant  effort  is  the  European  Commission’s  EIF,  which  was  released  initially  in  2004 
and  is  currently  undergoing  a  revision  [European  Commission  2004,  European  Communities 
2008].  While  the  first  version  of  the  EIF  provided  a  similar  overview  of  the  interoperability  chal¬ 
lenges  as  the  GIF,  draft  2.0  of  the  EIF  is  much  more  robust  in  addressing  more  than  just  technical 
interoperability.  As  we  discussed  earlier,  although  we  disagree  with  its  classification  of  legal  and 
political  factors  as  levels  of  interoperability,  the  new  version  of  the  EIF  effectively  highlights  the 
importance  of  these  factors  and  provides  useful  guidance  for  addressing  them. 

In  developing  specific  strategies,  countries  such  as  the  United  Kingdom,  the  Netherlands,  and  Es¬ 
tonia  have  made  significant  progress  on  the  e-govemment  interoperability  challenge  [Malotaux 
2007,  pp.  22-27].  One  survey  has  also  found  that  Austria  and  Malta  lead  the  way  in  sophistication 
and  availability  [Wauters  2007].  The  efforts  in  these  countries,  as  well  as  a  number  of  others,  can 
help  serve  as  a  guide  for  other  efforts. 

Finally,  the  United  States  and  Canada  have  taken  a  different  approach  to  e-govemment  interoper¬ 
ability  by  leveraging  enterprise  architecture  (EA)  frameworks  such  as  the  Zachman  Framework 
and  the  Open  Group  Architecture  Framework  [Open  Group  2008;  Zachman  International  Enter¬ 
prise  Institute  2008;  CS  Transform  2009,  p.  3;  Inside  Architecture  Blog  2009].  The  U.S.  govern¬ 
ment  also  provides  a  number  of  guidance  documents  on  EA  frameworks  currently  in  use  in  e- 
govemment  efforts  [White  House  0MB  2011]. 
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6  Conclusion 


Systems  interoperability  is  contextual.  A  corollary  to  this  statement  is  that  interoperability  is  not  a 
characteristic  of  a  single  system  but  rather  a  characteristic  of  the  relationship  between  two  or  more 
systems  in  a  particular  context.  The  context  in  which  systems  have  to  interoperate  shapes  the  re¬ 
quirements  that  each  individual  system  has  to  satisfy  in  order  for  it  to  interoperate  with  other  sys¬ 
tems.  Thus,  developers  need  to  plan  system  components  around  both  technical  and  nontechnical 
aspects  of  interoperability.  A  development  team  can  analyze  interoperability  in  any  context  along 
technical,  semantic,  and  organizational  dimensions,  but  the  diversity  and  complexity  of  the  legal, 
political,  and  sociocultural  dimensions  of  the  e-govemment  context  make  interoperability  chal¬ 
lenging  for  e-govemment  systems. 

The  model  proposed  in  this  report  captures  the  differences  between  technical,  semantic,  and  or¬ 
ganizational  interoperability  while  highlighting  the  crosscutting  impact  of  legal,  political,  and  so¬ 
ciocultural  issues  as  influencing  factors.  The  goal  of  this  model  is  to  reinforce  that  developers 
need  to  characterize  interoperability  in  the  e-govemment  context  along  the  six  dimensions  of  the 
model  so  that  they  can  understand,  discuss,  and  analyze  it.  If  e-govemment  system  designers  bet¬ 
ter  understand  the  problem  of  interoperability  and  account  for  context-dependent  influencing  fac¬ 
tors,  we  predict  that  more  e-govemment  efforts  will  succeed. 
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